Most databases write their data into data area asynchronously and use logging to store operations done on the data synchronously to the log. To guarantee the recoverability of the data in a catastrophic situation, both data and log areas are backed up to some tertiary medium (e.g., set of backup tapes). Usually, the data area is backed up periodically (e.g., once a day) and new log segments in the log area are backed up as soon as they are closed. In case of a catastrophic situation requiring data recovery, the data area is recovered from a backup to an older state (last valid data backup). Replaying backed up log segments backed up after this data backup will bring the database to the last committed state contained in the backed up log (and if the log area is still available, replaying further not-yet-backed-up log segments from the log area even to the last committed state while the database system was online).
When the recovery is finished, a new log segment will be started, where new data will be written. This process may invalidate certain portion of the log. In addition, in enterprise settings, there are usually many databases in production and they may be even copied/cloned, so it is possible that a system administrator might select an incorrect backup and try to restore from it. In most cases, this will lead to severe data errors and database crashes.
Other issues may arise in high availability settings in which the same database is kept in a master mode and a hot-standby mode using log shipping to a remote location. When temporarily both master and hot standby run at the same time, and log backups are taken on both, during take-over there can be an ambiguous recovery path. This recovery path has to be detected and resolved in order to ensure consistent recovery.